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ABSTRACT 


Comparisons are made between commercial 
packet-switching applications and the 
unique Amateur radio environment. Sugges-— 
tions for enhancing the AX.25 Level Two 
protocol are given. 


BACKGROUND 


In October, 1982, a special meeting was 
held in conjunction with the AMSAT Annual 
Meeting to define a Level Two protocol. 
Representatives from many Packet groups 
were present, and adopted a modified ver- 
sion of the AMRAD-sponsored AX.25 Level 
Two protocol. 


Since that time, AX.25 has become the de 
facto standard Level Two protocol in the 
United States and many other countries. 


Tucson Amateur Packet Radio (TAPR) imple- 
mented this new protocol (with a few not-— 
able extensions) in December, 1982, on its 
then-current "Beta" Terminal Node Control- 
ler. These devices saw widespread distri- 
bution beginning in January, 1983. 


Since that time, over 700 TAPR TNCs have 
been placed in the field and the exten- 
sions have had widespread acceptance. With 
experience have come requests for certain 
other changes to the protocol these 
requests form the basis of this paper. 


COMMERCIAL APPLICATION 


X.25 (the basis for AX.25) is used in 
commercial packet-switching networks. 
There are specific features to this proto- 
col that allow for such things as asses-— 
sing connection charges and the like, but 
a primary philosophical factor reflected 
in the protocol is that of "point-to- 
point" connections. 


To expand on this thought, X.25 assumes 
that the "terminal node," or user, is 
connecting to a "host," or master, node. 
All communications to and from the user go 
through this host. This, of course, makes 
it easy for the host to log connect time 
and otherwise supervise the network so 


each user gets his bill on time! 


Another feature allowed in X.25 is the so- 
called "balanced mode," where two nodes 
are connected as equals; there is no mas- 
ter/slave connotation. This is the mode 
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that has been adapted to Amateur use. 


Balanced made has two outstanding features 
that are particularly useful for radio 
Amateurs. 


every station has the same privi- 
leges. This is necessary in a "controlled 
anarchy" environment such as Amateur ra- 
dio. Any station can initiate a connection 
(QS0) and any connected station can 
initiate a disconnect. 


First, 


Second, by not requiring any master sta- 
tion, the system is very robust. Failure 
of any particular node does not cause the 
network to fail. 


Amateur Needs 


Amateur radio has some specific needs, 
however, that are not addressed by X.25. 
One of these needs relates to the address 
field: AX.25 provides a useful solution by 
encoding the Amateur call sign in the 
address field of the header and allowing 
up tol6 stations per Amateur call via the 
Secondary Station ID (SSID) portion of the 
address. 


Another need is related to the geographic 
area that a "local area" network may have 
to encompass. What happens if your station 
is behind ahillandyou cannot access the 
local Packet bulletin board system? 


AX.25 provides for a "digipeater." This is 
an intermediate station that can be speci- 
fied by the initiator of a connection to 
act as a relay between the two end sta- 
tions. While this application violates 
"pure" level two protocol, it satisfies a 
real need. 


When TAPR was implementing AX.25 for the 
first time, the software team (Margaret 
Morrison, KV7D, David Henderson, KD4NL, 
and Harold Price, NK6K) saw a need for 
multiple digipeaters. Since AX.25 didn't 
allow for this, they decided upon an AX.25 
compatible scheme. 


Basically, three digipeaters were allowed 
to be specified in the "VIA" argument in a 
connect request. Each station that re- 
ceived the packet scanned the digipeat 
field and looked for the first "I haven't 
been digipeated yet" bit that wasn't tog- 
gled to the "I just digipeated this frame" 
state. It then toggled the bit and trans- 


mitted the resultant packet. The end re- 
cipient simply reversed the order of the 
digipeater list, cleared the digipeated 
bits and sent the reply. 


Since digipeating allows for end-to-end 
ACKs only, the NAK being implicit, some 
mechanism had to be found to give digi- 
peated traffic priority in a net. This was 
solved via the DWAIT parameter. Essential- 
ly, every packet transmission that is not 
a digipeated packet waits the usual random 
backoff time, but always waits a minimum 
of DWAIT * 40 mSec. Digipeated packets do 
not wait this delay; they have priority on 
the channel. 


This feature was found to be very useful 
in such areas as Los Angeles-San Diego and 
the greater St. Louis area. 


When the TAPR kit TNC was developed, a new 
software release was simultaneously re- 
leased. The Version 3 software allows up 
to eight digipeaters to be specified, and 
also allows the use of digipeaters in the 
beacon and unconnected modes of operation. 


Since this extension is a violation of the 
AX.25 protocol as adopted at the AMSAT 
meeting, the TAPR implementation allows 
for totally compatible operation as long 
as not more than one digipeater is speci- 
fied by the user. It is hoped that other 
packet groups will recognize the benefits 
of allowing multiple digipeaters, and at 
such time as an AX.25 Level Two protocol 
review meeting is held with participation 
by interested Packet groups, TAPR will 
formally propose that these extensions be 
incorporated in the protocol. 


While on the subject of implemented exten 
sions to AX.25 Level Two, TAPR has exten- 
ded the use of the Disconnected Mode (DM) 
frame. 


AX.25 specifies that this frame will be 
sent only when the addressed station is in 
the disconnected mode and receives a frame 
other than a connect request (SABM). 


The TAPR TNC has a command thatallowsthe 
operator of the station to set a CONnect 
OK (CONOK) flag to OFF, thus inhibiting 
his TNC from being connected to. This 
allows the operator to listen on the chan- 
nel without having to "talk" to anyone. 
Under these conditions, a SABM frame will 
be responded to with a DM frame. 


The other non-standard sending of a DM 
frame occurs when the destination TNC is 
already connected to another station. 


The station requesting the connection, if 
in CONVERSation mode (not TRANSparent 
mode), will get a message stating 


**k*k <call> busy 


when a DM frame is received. Likewise, the 
station sending the DM frame will display 


*kR Connect request from <ceall> 


to alert him that a(nother) station wishes 
to connect. 


OTHER EXTENSION 


There are two other cases that arise in 
common Amateur practice that the author 
believes should be addressed at "Level 
Two" in Amateur Packet radio. 


The first is the case of multiple simul- 
taneous connections. This occurs when more 
than one station desires to use the ser- 
vices of another station. 


A "sort of" case of this occurs when one 
station is in a good location and becomes 
a digipeater used by other stations in the 
local area. While no connection exists to 
a digipeater (only through it), the sta- 
tion so used is an illustrative example of 


of multiple connections. 


One of Packet's widely touted benefits is 
its time domain multiplexing (TDM) ona 
given channel. This allows multiple QSOs 
to take place, increasing channel utiliza- 
tion. However, when a Packet station con- 
nects to the local Packet bulletin board, 
it becomes apparent that the bulletin 
board is being underutilized. Other sta- 
tion must wait in line for the first sta- 
tion to disconnect before the next one can 
connect. Meanwhile, the BBS is often stan- 
ding idly by while the connected user 
browses through his mail or digests some- 


thing just read. 


If multiple connections were allowed, many 
users could potentially access the BBS at 
the same (apparent) time. 


Please note that this is a question of 
implementation of AX.25 Level Two -- no- 
thing in the protocol prohibits multiple 
connections. The upcoming Version 4 soft- 
ware release for the TAPR INC will allow 
such multiple connections. 


One major difference between Amateur oper- 
ation and commercial practice is in the 
use of roundtables. This is a mode of 
operation where there are several stations 
that are engaged in a multi-way conversa-— 
tion. 


Such operation is very useful when one 
wants inputs from a number of others on a 
particular subject, or when a traffic net 
has items of general interest (a swap net 
comes to mind as a typical example). 


AX.25 Level Two does not allow for this 
mode of connection. While the next lay- 
er(s) of protocol will undoubtedly allow 
some semblance of this kind of operation, 
it will probably be dependent on some sort 
of "master@' linking station. This may 
reduce the robustness of the local system, 
which could be especially critical in 
times of local emergency traffic handling. 
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It is the author's belief that such oper- 
ation is totally feasible within the Level 
Two environment by simply making use of 
the two "reserved" bits in the seventh 
octetofeachcall in the address field. 


While this is not a formal proposal, the 
idea is as follows. 


[1] The use of up to ten call signs is 
permitted in the address field (in the 
same manner as implemented in the TAPR- 
extended digipeater string). This allows 
up to nine destination stations in the 
multi-way connection. 


{2] If the two bits marked "RR" in the 
seventh octet of the call are set toa 
"11", the call is treated like a digipea- 
ter -- this allows digipeaters in the case 
of certain stations in the multi-way con- 
nect, but reduces the number of destina-— 
tion stations by the number of digipeaters 
specified. 


[3] If the 6th bit (counting from 0) in 
the seventh octet is a "@", such that the 
field marked "RR" is "198", the station is 
treated as a destination station in the 
multi-way connect. Such a station would 
scan the previous addresses to see if this 
framewastohavebeen sent via a digipea- 
ter, and if so, if it in fact has been 
digipeated. The station would then con- 
tinue the scan to see if it was requested 
as a digipeater for some other destination 
station in the multi-way connect. 


{4] If the station is a destination sta- 
tion, it would read the control byte and 
act accordingly. 


This mechanism allows a single packet 
transmission to be explicitly sent to 
multiple destinations, avoiding the inef- 
ficiencies that would result from a chan- 
nel bandwidth utilization standpoint if 
the sending station had to use the multi- 
ple connection approach and send a packet 
to each destination individually. 


The nextproblemto solveisthemanner in 
which ACKs are handled. 


Each destination station would only have 
to send an ACK to the station originating 
the packet in question. Thus, a non-multi- 
way packet would be sent, the digipeat 
field being assembled by reading the ad- 
dress list backwards from this destination 
station to the first encountered non- 
digipeater. 


A variation of the TAPR TNC DWAIT parame-— 
ter would be used, wherein the station 
initiating the ACK would hold off for some 
number of milliseconds times his position 
in the address field. This would avoid 
collisions in most cases, while stream- 
lining the ACK process -- a sort of slot- 
ted ACK. 


To clarify the above, assume a station 
sent the following address field (an * 
indicates a digipeater, a # indicates a 
destination station): 


WA7GXD |N@ADI *|N7CL #|NK6K #|N@ADI # 


In this case, WA7GXD is sending a packet 
to N7CL via N@ADI, to NK6K directly and to 
N@ADI directly. 


N7CL would ACK via N@ADI; NK6K and N@ADI 
would ACK directly, with N7CL sending the 
first ACK, followed closely by NK6K and 
N@ADI. 


If WA7GXD did not correctly receive the 
ACK from NK6K, the packet transmission 
would be repeated, but either (a) would 
only be sent to NK6K (Non-ACKers only) or 
(b) would be sent to all stations again, 
but the already-ACKed stations would ig- 
nore the packet because the N(R) and/or 
N(S) counters would not have been updated 
by WAT7GXD. 


This informal proposal is not being pre- 
sented with the idea that it is the best 
solution to a multi-way connection at 
Level Two: rather it is suggested as a 
possible, compatible means of achieving 
this end. 


CONCLUSION 


AX.25 Level Two has been proven as a work- 
able protocol in the Amateur Packet radio 
environment. With suitable extensions, 
based on field feedback from active Packet 
users, it can be made even more suitable 
for long term usage. 


Some extensions have been implemented and 
tested in the field for an extended period 
of time: these extensions have been out-— 
lined. 


The need for as-yet unimplemented exten-— 
sions to allow multiple and multi-way 
connections has been pointed out and a 
possible approach for multi-way connec-— 
tions suggested. 
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